This right solution to fix this test would be for gl_ClipDistance to be treated as a float instead of a float[1] in msl-out.

I guess we need some kind of type override system for this?

Thank you for taking a stab at this!

This right solution to fix this test would be for gl_ClipDistance to be treated as a float instead of a float[1] in msl-out.

Are you sure this is the right solution? I think there may be multiple clip distances, technically, so if we implement this workaround, we'll be back at square one with regards to general support for this.
Instead, the subject of this PR sounds more reasonable. I do wonder if we should simply wrap all of the arrays...

Are you sure this is the right solution? I think there may be multiple clip distances, technically, so if we implement this workaround, we'll be back at square one with regards to general support for this.
Instead, the subject of this PR sounds more reasonable. I do wonder if we should simply wrap all of the arrays...

Yeah I just realised that table 5.3 of https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf states that it can be an array of floats. I'll have a go at using the array type in the output struct so instead of type6 gl_ClipDistance1 [[clip_distance]]; we have float[1] gl_ClipDistance1 [[clip_distance]];

Instead, the subject of this PR sounds more reasonable. I do wonder if we should simply wrap all of the arrays...

To clarify, the reason we can't do is is because a wrapped array doesn't count for [[clip_distance]]:

<stdin>:40:30: error: type 'type6' is not valid for attribute 'clip_distance'
    type6 gl_ClipDistance1 [[clip_distance]];
                             ^~~~~~~~~~~~~

I think what I've got here works pretty well now. Just FYI, what spirv-cross does in these situations is that it creates a template struct like:

template<typename T, size_t Num>
struct spvUnsafeArray
{
    T elements[Num ? Num : 1];
    
    thread T& operator [] (size_t pos) thread
    {
        return elements[pos];
    }
    constexpr const thread T& operator [] (size_t pos) const thread
    {
        return elements[pos];
    }
    
    device T& operator [] (size_t pos) device
    {
        return elements[pos];
    }
    constexpr const device T& operator [] (size_t pos) const device
    {
        return elements[pos];
    }
    
    constexpr const constant T& operator [] (size_t pos) const constant
    {
        return elements[pos];
    }
    
    threadgroup T& operator [] (size_t pos) threadgroup
    {
        return elements[pos];
    }
    constexpr const threadgroup T& operator [] (size_t pos) const threadgroup
    {
        return elements[pos];
    }
};

and returns that in functions instead:

static inline __attribute__((always_inline))
spvUnsafeArray<float, 1> xyz()
{
    spvUnsafeArray<float, 1> y;
    return y;
}

This means that they don't have to do .inner at all.

Are we all set?

Are we all set?

I think so! I hope this doesn't break any vertex shaders.

I'm royally confused about how C arrays work, and that is going to make the maintenance of this code to be difficult.
But you've really done a great job implementing it, and it addresses a very important issue we have, and there isn't any cleaner solution that we know. So let's proceed!